The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
Individuals and companies generate an enormous amount of data in documents and store those documents on file servers, which use network file system (NFS), server message block SMB, or other protocols to send and receive document to and from clients on a network. If a user desires to view or edit a document, then the user normally maps a folder on a remote file server to a local folder or drive. A document editor (such as OpenOffice™ or Microsoft Office™) treats the document exactly the same way as a local file. Thus, when the editor opens a document, the document editor reads the entire document from the file server. For larger document, some editors may only read only the accessed portion of documents. After the user changes the document, no matter how large or small the change, the document editor saves the entire document.
For example, user Tom writes a book with hundreds of pages and graphs using a traditional document editor. The corresponding document requires five megabytes (5 MB) of data. Each time user Tom changes a paragraph and saves the document, the document editor saves the entire 5 MB to disk. Such constant saving leads to significant performance issues.
If the document is stored on a remote server, then the performance issues become more significant. For example, if network bandwidth is 100 Kb/s, the response time for saving a 5 MB file is (5000 K*8 b/B)/100/60=6.7 minutes, which is not acceptable.